Cross-profiling for Java processors

ion with a boolean method isCacheHit(. . . ) that takes as argument a method identifier. The user has to provide an appropriate implementation of the CacheStrategy for the target processor. The UML class diagram in Figure 2 shows two concrete implementations, CacheJOP and CacheX. After consulting the configured CacheStrategy, the default implementation of EnterReturnProfiler invokes the CycleEstimator to compute the cycles consumed by the method invocation/return. In addition to a bytecode, getCycles(. . . ) also takes information about the method size and whether the method was found in the cache (for bytecodes other than method invocation/return, this extra information is meaningless and ignored by implementations of getCycles(. . . )). The cycle estimate is added to the cycle counter in the appropriate CCT node (i.e. in the caller node for method invocation, respectively, in the callee node for method return). For the method return pointcut, the instrumentation component exactly knows the return bytecode and passes it as argument to onMethodReturn(. . . ). However, for the method entry pointcut, the instrumentation component cannot always determine which invocation bytecode will be used by the caller. A method that is also declared in an interface may be called with the invokevirtual bytecode or with the invokeinterface bytecode. Furthermore, one use of invokespecial is to access a superclass’ version of a method (this mechanism is used to compile Java’s super() construct). That is, in certain cases the same method may be called by invokevirtual, invokeinterface, or invokespecial. However, as the CPU cycle consumption of the distinct method invocation bytecodes may differ, knowing that the concrete invocation bytecode can help improve the accuracy of cross-profiling. As general solution, we can pass the information regarding the method invocation bytecode from the caller to the callee as an extra method argument. For invocations of static methods, private methods, and constructors, the extra argument is not needed, because the invocation bytecode is statically known (both when instrumenting the caller method(s) and the callee method)∗∗. Note that in general, the method entry pointcut cannot be implemented by instrumenting the caller, because of polymorphic call sites (where the method identifier of the callee would not be known). In contrast, the method identifier of the caller is always known to the callee, since the caller passes its CCT node to the callee. Another issue is abnormal method completion through an exception. In this case, onMethod Return(. . . ) is not invoked. A general solution to this issue would be the introduction of another pointcut (corresponding to a method onMethodAbnormalCompletion(. . . ) in EnterReturnProfiler), which could be implemented by an inserted exception handler. In contrast to CProf, prevailing AOP frameworks, such as AspectJ [36], provides mechanisms for intercepting abnormal method completion. However, because exception throwing is infrequent in embedded Java software, CProf currently lacks such a mechanism. ∗∗The instrumentation component can statically determine whether a callee is private, since it processes all methods within the same class file, and private methods can only be called in the defining class. Constructor invocations are identified by the special method name 〈init〉. Copyright q 2009 John Wiley & Sons, Ltd. Softw. Pract. Exper. (2009)